Understand the meaning, significance and foundational components of research, including the formulation and evaluation of research problems.
The selection of a research problem is the single most consequential decision in the research lifecycle. An elegant methodology, a sophisticated toolchain or a powerful statistical model cannot rescue a study built on a poorly chosen problem. Conversely, a well-selected problem — even investigated with modest resources — tends to produce useful, publishable and citable contributions.
This lecture answers two complementary questions: what makes a research problem good? (the essential attributes, Section 2) and what makes one bad? (the selection errors, Section 4).
The ATTR-FEAS checklist in Section 3 consolidates the attributes into eight diagnostic questions. Memorise it: examiners ask you to apply it to a given problem statement, and it is also the fastest way to audit your own project proposal.
1. Learning Objectives
- Describe the essential attributes that distinguish a scientifically sound research problem from a trivial or unworkable one.
- Apply a structured set of evaluative criteria when shortlisting a research problem in computer science.
- Identify and diagnose the common errors researchers commit at the problem-selection stage.
- Reframe a poorly stated problem into a well-defined one using practical heuristics.
- Connect the abstract qualities of a “good” problem to concrete CS research scenarios — algorithms, networks, AI/ML, software engineering.
2. Essential Attributes of a Good Research Problem
The attributes are interrelated: weakness in one often compromises the others. They group under three meta-categories — conceptual quality, operational feasibility and strategic value.
2.1 Conceptual Quality
Clarity and precision of statement. The problem must be expressed in unambiguous, operationally defined terms. Vague verbs such as study, understand, look at or explore the area of should be replaced with precise verbs: evaluate, compare, predict, classify, optimise.
Poor: “Study deep learning.”
Improved: “Evaluate the impact of activation-function selection (ReLU, GELU, Swish) on the convergence speed of residual CNNs trained on CIFAR-10.”
Novelty and originality. Novelty is relative and can be expressed along several dimensions, and a problem need not be novel in every one — CS theses routinely make methodological or empirical contributions alone:
- Theoretical novelty — a new model, proof or complexity bound.
- Methodological novelty — applying an existing method to a new domain, or refining it non-trivially.
- Empirical novelty — new evidence on a contested question, for instance benchmarking a new optimiser across heterogeneous hardware.
- Application novelty — deploying an established technique against a previously unsolved practical problem.
Theoretical grounding. A problem should arise from an identifiable body of literature and contribute back to it. You must be able to position the work with respect to at least one established theory — PAC learning, information theory, queueing theory, type theory, software metrics theory.
Testability and falsifiability. Following Popperian epistemology, a problem should admit hypotheses that can in principle be refuted. In computing this means questions whose answers rest on measurable outcomes: does the proposed algorithm reduce worst-case time complexity? Does the model achieve statistically significant gains in F1 on a held-out test set? Does the protocol lower end-to-end latency under specified load? A problem that cannot, even in principle, be refuted is closer to speculation than to research.
2.2 Operational Feasibility
Researchability. The problem must be investigable using available or obtainable methods. One demanding access to a hyperscale data centre or proprietary industrial control systems may be theoretically interesting but practically unresearchable for a student.
Feasibility of data acquisition. Empirical CS research depends on data — benchmark datasets, log files, survey responses, simulation traces. The problem must specify the sources and confirm they are accessible, ethical, and of adequate volume and quality. For quantitative work a rough sample-size awareness helps; comparing two means with expected effect size d, the normal approximation gives a per-group size of:
where z1−α/2 and z1−β are the standard normal deviates for the significance level and the statistical power. A problem whose data requirements vastly exceed the attainable n is not feasible.
Compatibility with the researcher's competence. The problem should lie within, or just beyond, the existing skill envelope. A novice attempting quantum algorithm design or category-theoretic semantics without preparation is unlikely to produce credible work.
Manageability of scope. Over-scoping is a common failure mode. Scope must be commensurate with the time, computing and human resources available: a manageable problem produces at least one defensible contribution within the stipulated duration.
Ethical acceptability. The problem must conform to institutional norms — responsible data handling, avoidance of harm from deployed AI systems, and compliance with ethics-committee requirements.
2.3 Strategic Value
- Relevance and significance. The problem should matter to the discipline, to industry or to society. Significance is established by a gap explicitly acknowledged in prior surveys, a pain point documented in industry reports, or a theoretical contradiction that warrants resolution.
- Timeliness. Applied CS problems are especially time-sensitive because platforms evolve rapidly — LLM architectures, edge devices, 6G networks.
- Generative potential. A truly fertile problem, once solved, opens three new avenues rather than closing the field.
- Interest and motivation. Intrinsic interest is not a luxury but a strategic asset: it sustains the inevitable periods of dead-end debugging, negative results and reviewer criticism.
3. The ATTR-FEAS Checklist
| Letter | Attribute | Diagnostic question |
|---|---|---|
| A | Aim clarity | Can the problem be stated in one unambiguous sentence? |
| T | Testability | Can at least one falsifiable hypothesis be formulated? |
| T | Theoretical link | Is the problem grounded in an identifiable literature? |
| R | Relevance | Does the problem matter to a recognised community? |
| F | Feasibility | Are data, tools and skills realistically available? |
| E | Ethical soundness | Does the study pass an ethics review? |
| A | Achievability of scope | Can the work be completed in the allotted time? |
| S | Significance of contribution | Will the outcome advance knowledge or practice? |
A problem scoring affirmatively on at least seven of the eight items is generally defensible.
4. Errors in the Selection of a Research Problem
Selection errors fall into five families, each illustrated below with a typical computing scenario.
4.1 Errors of Scope
- The over-broad problem. Symptom: the statement covers an entire subfield — “improve the performance of deep neural networks”. This cannot be answered in any finite study. Remedy: narrow by algorithm, dataset, hardware or task.
- The over-narrow problem. Symptom: the problem addresses a trivial special case — “optimise a bubble sort routine on a 32-element array of integers”. The result will not generalise or interest anyone. Remedy: generalise by parameter, structure or domain until the result is indicative of a class of phenomena.
4.2 Errors of Conceptual Grounding
- Insufficient literature review. Selecting without an adequate scan leads to duplication; a problem already solved is wasted effort even if the solver is unaware of the prior work. Remedy: conduct a systematic mapping or scoping review before finalising.
- Absence of a theoretical framework. A problem unanchored in theory produces descriptive but not explanatory results — reporting that Model A outperforms Model B without invoking any learning-theoretic explanation. Remedy: identify at least one theoretical lens (bias–variance decomposition, VC dimension, software evolution theory) and design around it.
4.3 Errors of Empirical Design
- Unavailability of data. A problem requiring proprietary, sensitive or practically inaccessible data is non-researchable — a thesis requiring millions of patient ECG records without a hospital collaboration. Remedy: secure the data through formal agreement, or reframe around publicly available surrogates.
- Inadequate measurement instruments. Constructs that cannot be reliably measured yield noisy, uninterpretable results — measuring “code quality” using only lines of code. Remedy: validate the instruments, through inter-rater reliability for human-coded data or established benchmarks for algorithmic comparison.
4.4 Errors of Motivation and Context
- Fad-driven selection. Choosing a problem because it is fashionable — “I want to work on blockchain”, “I want to fine-tune an LLM” — without a genuine research question leads to shallow work. Remedy: begin with the question, not the technology. The tool should serve the question, not the reverse.
- Adviser-driven selection without ownership. A problem imposed without the student's intellectual buy-in tends to produce low-quality dissertations. Remedy: negotiate ownership of a sub-problem that genuinely interests you while still aligning with the larger grant.
- Politically convenient topics. Problems selected because they are safe or aligned with institutional branding can be technically correct but lack intellectual edge. Remedy: look for the genuine intellectual tension inside the safe topic.
4.5 Errors of Self-Assessment
- Problem beyond competence. Designing a novel cryptographic primitive without a background in number theory or complexity theory is unlikely to produce credible work. Remedy: upskill systematically, or select a problem one tier below the current frontier.
- Problem beneath interest. A problem selected purely for ease — the “safe PhD” — rarely produces the deep engagement original work requires. Remedy: aim for the intersection of competence, interest and significance, under the additional constraint of feasibility.
- Ignored cost and time constraints. A problem whose solution requires a six-month cluster run on a personal laptop is an error of planning rather than of conception. Remedy: estimate resource budgets — compute hours, storage, personnel, calendar time — before finalising.
4.6 Diagnostic Summary
| Error family | Typical symptom | Most effective remedy |
|---|---|---|
| Scope | Problem too broad or too narrow | Restate with explicit boundary conditions |
| Conceptual | No theory, no literature anchor | Conduct a systematic literature review |
| Empirical | No data, no instruments | Pilot data collection early |
| Motivation | Fad-driven, externally imposed | Reframe around genuine intellectual tension |
| Self-assessment | Beyond competence, beneath interest | Calibrate scope to the researcher profile |
5. Case Studies
“Evaluate the detection latency and false-positive rate of a transformer-based intrusion detection system against three baselines (signature-based Snort, random forest, and LSTM) on the CICIDS-2017 dataset, under class-imbalanced conditions.”
- Clear aim — the comparison is operationalised through two metrics.
- Novelty — applying transformers to a class-imbalanced IDS task is non-trivial.
- Feasibility — CICIDS-2017 is public and the baselines are open-source.
- Testability — hypotheses are explicit, for instance H0: no significant difference in detection latency at α = 0.05.
- Relevance — intrusion detection is a perennial security concern.
“Investigate artificial intelligence.” This violates nearly every attribute: no scope, no testable hypothesis, no theoretical anchor, no feasibility boundary, no measurement. It is not a problem but a topic.
Reframed: “Quantify the effect of curriculum learning on the sample efficiency of vision transformers fine-tuned for medical image classification under a fixed compute budget of 100 GPU-hours.”
“Train a foundation model for Indian legal text from scratch and benchmark it against GPT-4.” The compute cost of pretraining is incompatible with a B.Tech or M.Tech budget, and benchmarking against a proprietary model introduces intellectual-property and reproducibility problems.
Reframed: “Fine-tune an open-source 7B-parameter LLM on a curated Indian legal corpus and evaluate its performance on three downstream tasks: case summarisation, statutory QA, and judgement classification.” The reframing retains the original motivation while rendering the study feasible.
6. Summary
The selection of a research problem is not an act of inspiration but an act of disciplined evaluation. A good problem in computer science is simultaneously clear, novel, theoretically grounded, testable, feasible, ethical, manageable and significant; the ATTR-FEAS checklist operationalises these into a reusable diagnostic.
Equally important is the diagnosis of selection errors, which fall into five families — errors of scope, of conceptual grounding, of empirical design, of motivation, and of self-assessment. Recognising them early converts a doomed study into a salvageable one through reframing.
The best research problem is one that, when stated aloud, a peer in the same subfield can criticise constructively — because what can be criticised is what can be improved, and what can be improved is what can be defended.
7. Exam Preparation
- Memorise the ATTR-FEAS heuristic and be able to apply it to any given problem statement.
- Prepare two contrasting examples — one well-formed, one poorly formed — from your own area of interest.
- Be able to reframe a vague problem into a precise, testable one; examiners test this skill directly.
- Distinguish conceptual from operational errors in problem selection.
- Practise writing hypotheses in null and alternative form, with the corresponding test statistic.
7.1 Short-Answer Questions
- State and justify any five essential attributes of a good research problem. 5 marks
- Differentiate between an over-broad and an over-narrow research problem, giving one computing example of each. 3 marks
- Explain why “novelty” should not be confused with “complexity” in problem selection. 3 marks
- Why is theoretical grounding important even for an empirically oriented CS thesis? 3 marks
7.2 Long-Answer and Applied Questions
- A peer proposes the problem “Make cloud computing faster”. Diagnose the errors and rewrite it as a well-formed research problem in distributed systems or cloud resource management. 10 marks
- For each attribute in the ATTR-FEAS checklist, give one diagnostic question you would pose to a student presenting a research proposal. 8 marks
- A funding agency offers a grant to study “AI for healthcare” but specifies completion in 18 months with a single GPU workstation. Discuss the ethical, feasibility and scope concerns, and propose a defensible formulation. 12 marks
7.3 Higher-Order Question
For each of the following, classify the primary error — scope, conceptual, empirical, motivational or self-assessment — and propose a one-paragraph reframing that preserves the underlying motivation:
- “Build a chatbot that talks like a human.”
- “Prove P ≠ NP.”
- “Survey all machine-learning algorithms ever published.”
- “Reimplement TensorFlow from scratch in a new language.”
8. Suggested Further Reading
- Kothari, C. R., & Garg, G. (2019). Research Methodology: Methods and Techniques (4th ed.). New Age International.
- Creswell, J. W., & Creswell, J. D. (2018). Research Design (5th ed.). SAGE.
- Wohlin, C., et al. (2012). Experimentation in Software Engineering. Springer. — chapter on defining the experimental goal.
- Kitchenham, B. A., & Charters, S. (2007). Guidelines for Performing Systematic Literature Reviews in Software Engineering. EBSE Technical Report.
- Popper, K. (2002). The Logic of Scientific Discovery (reprint). Routledge. — for the falsifiability criterion.